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MULTI-LINGUAL TAG EXTENSION MECHANISM 



BACKGROUND OF THE INVENTION 

This application claims priority from U.S. Provisional Application Number 
60/141,071, filed June 25, 1999, Attorney Docket No. SUN1P249P/P4205PSP, entitled 
5 "JAVA SERVER PAGES SPECIFICATION"; and claims priority from U.S. Provisional 
Application Number 60/149,508, filed August 17, 1999, Attorney Docket No. SUN1P260P, 
entitled "JAVASERVER PAGES SPECIFICATION"; and is related to U.S. Patent 

Application Number , entitled "MECHANISM FOR AUTOMATIC 

SYNCHRONIZATION OF S CRIPTING VARIABLES" attorney docket number 

= 10 SUN1P254/P4195, filed ; the applications are commonly assigned to the 

assignee of the present invention, and the disclosures of which are herein incorporated by 
reference. 

1. Field of the Invention 

The present invention relates generally to the field of computer software, and more 
15 particularly to a multi-lingual tag extension mechanism suitable for use with JavaServer 
Pages ™. 

2. Description of the Related Art 

JavaServer Pages™ is the Java platform technology for building applications 
containing dynamic Web content such as HTML, DHTML, XHTML, and XML. A 
20 JavaServer Page (JSP) is a text-based document that describes how to process a request to 
create a response. The description inter-mixes template data with some dynamic actions, 
taking advantage of the capabilities of the Java platform. A JSP page can dynamically create 
certain types of text, while inter-mixing standard HTML tags. 



A simple example of a JSP page is shown in Figure 2. The example shows the 
response page, which is intended to be a short list of the day of the month and year, at the 
moment the request is received by the server. The page itself contains some fixed template 
text, and JSP elements that are shown underlined in the figure. The underlined actions are 
executed on the server side. When a client makes a request, such as an HTTP request, a 
request object requests a response from the JavaServer container. The first element creates a 
Java Bean named clock, of type calendar.jspCalendar. The next two elements use the Bean to 
display some of its properties (i.e. month and year). The output is sent to a response object 
which sends a response back to the client. 

A JSP page is executed by a JSP container, which is installed on a Web server, or on a 
Web enabled application server. The JSP container delivers requests from a client to a JSP 
page and responses from the JSP page to the client. JSP pages maybe implemented using a 
JSP translation or compilation phase that is performed only once, followed by a request 
processing phase that is performed once per request. The translation phase creates a JSP page 
implementation class that implements a servlet interface. 

Typically, a JSP page contains declarations, fixed template data, action instances that 
maybe nested, and scripting elements. When a request is delivered to a JSP page, all these 
components are used to create a response object that is then returned to the client. As with 
standard Web pages, JSP pages may contain "tags." In order to facilitate the construction of 
Web pages, standard page formatting codes, known as tags, are provided. A tag is a textual 
element within a document that provides instructions for formatting or other actions. For 
example, World Wide Web documents are set up using HTML (Hyper-Text Mark-up 
Language) tags which serve various functions such as controlling the styling of text and 
placement of graphic elements, and also providing links to interactive programs and scripts. 



In standard implementations, a JSP page is translated into Java code that runs on a 
server. The transformation from the JSP page into Java code is done once, when the page is 
first accessed. The Java code running on the server is activated when a request is received. 
In order to create a response object, certain data is passed verbatim to the response, and some 
actions are executed on the server side. Some of these actions are explicitly spelled out in the 
JSP page, and other actions are described by the semantics of the text. Thus, there are three 
types of code: verbatim code, scripting code from the JSP page, and code which has to be 
defined by the tag library. As used herein, "tags" in the JSP context will be referred to as 
"actions." 

Ideally, a tag mechanism employed in a JSP page system would allow for actions to be 
defined in standard libraries. This would allow third parties to provide new actions as part of 
their JSP authoring tools. For example, as shown in Figure 3, a JSP page author may use a 
JSP specification-compliant authoring tool to create a Web page. The vendor of the authoring 
tool can provide new actions via a JSP tag library, such as a tag library that supports chat 
room functionality. The page can then be deployed into any JSP-compliant container, such as 
a Web browser. The Web browser uses the same tag library information in order to run the 
Web page, including the desired chat room functions. 

In other words, if a standard JSP tag mechanism is properly defined, vendors of tag 
libraries can use the standard specification to create tag libraries that are compliant with the 
JSP environment. Also, vendors of authoring tools can create authoring tools (and scripting 
languages) compliant with the specification, and vendors of Web browsers can create JSP 
compliant Web browsers. A Web page author can then choose the best tag library and the 
best authoring tool available for creating the desired Web pages. Two different Web 
browsers may support scripting in a completely different manner, but the same tag libraries 
must be supported by both in order to run the Web page. 



Therefore, in order to provide the desired functionality, the JSP specification needs to 
define the semantics of an extensible tag mechanism that can support the following 
constraints: 

• the tag mechanism can be implemented with minimal assumptions about the page 
implementation ( i.e. only "callability" from the page into the extension should be assumed); 

• minimal constraints on the page translation process are imposed; 

• supports tag body evaluation; 

• portable - a tag described in a tag library must be usable in any JSP container; 

• simple - a mechanism that is accessible and easy to use, both by users of the tags 
(JSP authors, creators of JSP authoring tools) and by authors of tags; 

• expressive - enable a wide range of actions; in particular: 

- nested actions 

- scripting elements inside the tag body 

- refer to scripting variables, and create and update scripting variables; and 

• usable from different scripting languages, not just Java. 

The more powerful the tag library mechanism, however, the more difficult it is to satisfy these 
constraints. 

Currently available commercial products do not provide the desired functionality. For 
example, Cold Fusion's CFX mechanism does not provide for body evaluations. Compilation- 
based mechanisms, such as LiveSoftware's Jrun mechanism, make significant assumptions 
about the page implementation details. Also, pure translation-based methods, like XSLT need 
to make assumptions about the scripting language. 

One prior art approach is to define the semantics of each tag through a transformation 
into a scripting language. The problem with this approach, however, is that the tag library 



author does not know the scripting language that will be used, so it is very difficult to define 
the transformation. A second approach relies on the concept of a "closure." In an evaluation 
system, a closure is a data structure that holds an expression and an environment of variable 
bindings in which that expression is to be evaluated. The variables may be local or global. 
5 • Closures are used to represent unevaluated expressions when implementing functional 
programming languages with lazy evaluation. 

Figure 4 illustrates how a tag can be translated into a closure. The idea of a closure is 
to encapsulate a tag "body" into a software object called a closure. A closure is a procedure 
with some context, such that the object can evaluate itself. The closure is instantiated and 
10 passed to an implementation of the tag library. The tag library can then execute the action 
and determine how many times to invoke the body if, for example, the body contains a loop. 

During the translation process, a tag "foo" in a JSP page (Figure 4) is transformed into 
a closure. An Implementation Class (type servlet) is created, with the code associated with 
the "Body" of the tag corresponding to the closure (i.e. the underlined code). When a request 
15 is received, an instance of the closure is passed to the tag library. The tag library then 

executes the action, using a single "dolt ( )" method. The main advantage of using a closure 
to perform the tag action is that no special knowledge is needed in order to execute the 
closure. Specifically, no knowledge is required of how variables are accessed, since the 
closure contains the necessary context. A closure is difficult to create, however, since it is 
20 difficult to provide the requisite context. In fact, the Java programming language does not 
support the use of closures. 

In view of the foregoing, there is a need for an extensible tag mechanism that can 
provide the desired functionality in Java, regardless of the scripting language used to develop 
the JSP page (i.e. multi-lingual), and which does not use a standard closure. 

25 
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SUMMARY OF THE INVENTION 

In general, the present invention is a multi-lingual tag extension mechanism suitable 
for use with the Java Server Pages platform. Rather than creating a closure abstraction, the 

5 present invention "in-lines" a body evaluation for the tags (i.e. actions). A doStart ( ) method 
processes a start tag and determines if a body needs to be evaluated. If so, a body evaluation 
buffer is passed to a doBody ( ) method for body evaluation. Once the body evaluation is 
completed, a doEnd ( ) method completes the processing by synchronizing the variables. The 
scripting details of the present invention match any nesting of the tag, so that the structure 

10 corresponding to the original scripting is preserved. Furthermore, the present invention is not 
dependent on the specifics of the scripting language in the JSP page used to form the 
response. 

The present invention thus enables the addition of new or custom actions, allowing the 
JSP "language" to be easily extended in a portable fashion. Tag libraries can be used by JSP 
15 authoring tools and can be distributed along with JSP pages to any JSP container, such as 
Web and application servers. The tag extension mechanism of the present invention can be 
used from JSP pages written using any valid scripting language, although the mechanism 
itself only assumes a Java RunTime environment. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 



The present invention will be readily understood by the following detailed description 
in conjunction with the accompanying drawings, wherein like reference numerals designate 
like structural elements, and in which: 



Figure 1 is a block diagram of a computer system suitable for implementing the 
present invention; 

Figure 2 illustrates a JSP page; 

Figure 3 is a diagram illustrating the relationship between a tag library, a JSP page, 
5 and a Web browser; 

Figure 4 illustrates an implementation of a closure; 

Figure 5 illustrates an implementation of the present invention; and 

Figure 6 illustrates the code of Figure 4 translated according to the present invention. 

10 DETAILED DESCRIPTION OF THE INVENTION 

The following description is provided to enable any person skilled in the art to make 
and use the invention and sets forth the best modes contemplated by the inventor for carrying 
out the invention. Various modifications, however, will remain readily apparent to those 
skilled in the art, since the basic principles of the present invention have been defined herein 

1 5 sp ecifically to provide a multi-lingual tag extension mechanism. 

The present invention employs various computer-implemented operations involving 
data stored in computer systems. These operations include, but are not limited to, those 
requiring physical manipulation of physical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals capable of being stored, transferred, 

20 combined, compared, and otherwise manipulated. The operations described herein that form 
part of the invention are useful machine operations. The manipulations performed are often 
referred to in terms, such as, producing, identifying, running, determining, comparing, 
executing, downloading, or detecting. It is sometimes convenient, principally for reasons of 
common usage, to refer to these electrical or magnetic signals as bits, values, elements, 

25 variables, characters, data, or the like. It should remembered, however, that all of these and 



similar terms are to be associated with the appropriate physical quantities and are merely 
convenient labels applied to these quantities. 

The present invention also relates to a device, system or apparatus for performing the 
aforementioned operations. The system may be specially constructed for the required 
purposes, or it may be a general purpose computer selectively activated or configured by a 
computer program stored in the computer. The processes presented above are not inherently 
related to any particular computer or other computing apparatus. In particular, various 
general-purpose computers may be used with programs written in accordance with the 
teachings herein, or, alternatively, it maybe more convenient to construct a more specialized 
computer system to perform the required operations. 

FIG. 1 is a block diagram of a general purpose computer system 100 suitable for 
carrying out the processing in accordance with one embodiment of the present invention. 
Figure 1 illustrates one embodiment of a general purpose computer system. Other computer 
system architectures and configurations can be used for carrying out the processing of the 
present invention. Computer system 100, made up of various subsystems described below, 
includes at least one microprocessor subsystem (also referred to as a central processing unit, 
or CPU) 102. That is, CPU 102 can be implemented by a single-chip processor or by 
multiple processors. It should be noted that in re-configurable computing systems, CPU 102 
can be distributed amongst a group of programmable logic devices. In such a system, the 
programmable logic devices can be reconfigured as needed to control the operation of 
computer system 100. In this way, the manipulation of input data is distributed amongst the 
group of programmable logic devices. CPU 102 is a general purpose digital processor which 
controls the operation of the computer system 100. Using instructions retrieved from 
memory, the CPU 102 controls the reception and manipulation of input data, and the output 
and display of data on output devices. 



CPU 102 is coupled bi-directionally with a first primary storage 104, typically a 
random access memory (RAM), and uni-directionally with a second primary storage area 106, 
typically a read-only memory (ROM), via a memory bus 108. As is well known in the art, 
primary storage 104 can be used as a general storage area and as scratch-pad memory, and can 

5 also be used to store input data and processed data. It can also store programming 

instructions and data, in the form of data objects, in addition to other data and instructions for 
processes operating on CPU 102, and is used typically used for fast transfer of data and 
instructions in a bi-directional manner over the memory bus 108. Also as well known in the 
art, primary storage 106 typically includes basic operating instructions, program code, data 

10 and objects used by the CPU 102 to perform its functions. Primary storage devices 104 and 
106 may include any suitable computer-readable storage media, described below, depending 
on whether, for example, data access needs to be bi-directional or urn-directional. CPU 102 
can also directly and very rapidly retrieve and store frequently needed data in a cache memory 
110. 

15 A removable mass storage device 1 12 provides additional data storage capacity for the 

computer system 100, and is coupled either bi-directionally or uni-directionally to CPU 102 
via a peripheral bus 1 14. For example, a specific removable mass storage device commonly 
known as a CD-ROM typically passes data uni-directionally to the CPU 102, whereas a 
floppy disk can pass data bi-directionally to the CPU 102. Storage 112 may also include 

20 computer-readable media such as magnetic tape, flash memory, signals embodied on a carrier 
wave, PC-CARDS, portable mass storage devices, holographic storage devices, and other 
storage devices. A fixed mass storage 116 also provides additional data storage capacity and 
is coupled bi-directionally to CPU 102 via peripheral bus 1 14. The most common example of 
mass storage 1 16 is a hard disk drive. Generally, access to these media is slower than access 

25 to primary storages 104 and 106. 
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Mass storage 112 and 116 generally store additional programming instructions, data, 
and the like that typically are not in active use by the CPU 102. It will be appreciated that the 
information retained within mass storage 112 and 116 may be incorporated, if needed, in 
standard fashion as part of primary storage 104 (e.g. RAM) as virtual memory. 
5 In addition to providing CPU 102 access to storage subsystems, the peripheral bus 114 

is used to provide access other subsystems and devices as well. In the described embodiment, 
these include a display monitor 118 and adapter 120, a printer device 122, a network interface 
124, an auxiliary input/output device interface 126, a sound card 128 and speakers 130, and 
other subsystems as needed. 
10 The network interface 124 allows CPU 102 to be coupled to another computer, 

computer network, or telecommunications network using a network connection as shown. 
Through the network interface 124, it is contemplated that the CPU 102 might receive 
information, e.g., data objects or program instructions, from another network, or might output 
information to another network in the course of performing the above-described method 
15 steps. Information, often represented as a sequence of instructions to be executed on a CPU, 
may be received from and outputted to another network, for example, in the form of a 
computer data signal embodied in a carrier wave. An interface card or similar device and 
appropriate software implemented by CPU 102 can be used to connect the computer system 
100 to an external network and transfer data according to standard protocols. That is, method 
20 embodiments of the present invention may execute solely upon CPU 1 02, or may be 

performed across a network such as the Internet, intranet networks, or local area networks, in 
conjunction with a remote CPU that shares a portion of the processing. Additional mass 
storage devices (not shown) may also be connected to CPU 102 through network interface 
124. 
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Auxiliary I/O device interface 126 represents general and customized interfaces that 
allow the CPU 102 to send and, more typically, receive data from other devices such as 
microphones, touch-sensitive displays, transducer card readers, tape readers, voice or 
handwriting recognizers, biometrics readers, cameras, portable mass storage devices, and 
5 other computers. 

Also coupled to the CPU 102 is a keyboard controller 132 via a local bus 134 for 
receiving input from a keyboard 136 or a pointer device 138, and sending decoded symbols 
from the keyboard 136 or pointer device 138 to the CPU 102. The pointer device maybe a 
mouse, stylus, track ball, or tablet, and is useful for interacting with a graphical user interface. 
10 In addition, embodiments of the present invention further relate to computer storage 

products with a computer readable medium that contain program code for performing various 
computer-implemented operations. The computer-readable medium is any data storage 
device that can store data which can thereafter be read by a computer system. The media and 
program code may be those specially designed and constructed for the purposes of the present 
15 invention, or they may be of the kind well known to those of ordinary skill in the computer 
software arts. Examples of computer-readable media include, but are not limited to, all the 
media mentioned above: magnetic media such as hard disks, floppy disks, and magnetic tape; 
optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and 
specially configured hardware devices such as application-specific integrated circuits 
20 (ASICs), programmable logic devices (PLDs), and ROM and RAM devices. The computer- 
readable medium can also be distributed as a data signal embodied in a carrier wave over a 
network of coupled computer systems so that the computer-readable code is stored and 
executed in a distributed fashion. Examples of program code include both machine code, as 
produced, for example, by a compiler, or files containing higher level code that may be 
25 executed using an interpreter. 
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It will be appreciated by those skilled in the art that the above described hardware and 
software elements are of standard design and construction. Other computer systems suitable 
for use with the invention may include additional or fewer subsystems. In addition, memory 
bus 108, peripheral bus 1 14, and local bus 134 are illustrative of any interconnection scheme 
5 serving to link the subsystems. For example, a local bus could be used to connect the CPU to 
fixed mass storage 116 and display adapter 120. The computer system shown in FIG. 1 is but 
an example of a computer system suitable for use with the invention. Other computer 
architectures having different configurations of subsystems may also be utilized. 

As the term is used herein, a tag extension mechanism is a specialized sub-language 
10 that enables the addition of new or custom actions, thus allowing the JSP "language" to be 
easily extended in a portable fashion. A typical example would be elements to support 
embedded database queries. Tag libraries can be used by JSP authors or JSP authoring tools 
and can be distributed along with JSP pages to any JSP container, such as Web and 
application servers. The tag extension mechanism of the present invention can be used from 
1 5 JSP pages written using any valid scripting language, although the mechanism itself only 
assumes a Java RunTime environment. 

In general, custom actions provide access to their attribute values and to their body. 
They can also be nested and their bodies can include scripting elements. For example: 
<foo attrl= "vail" attr2= "val2" . . .> 
20 [Body] 
</foo> 

where "Body" may itself have scripting elements or other actions that create or manipulate 
server side objects. 

In order to provide an extensible multi-lingual tag mechanism, the present invention 
25 implements a mechanism similar to a closure, but using three separate and distinct methods. 
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Under the closure approach, an object on the server side is created that corresponds to a 
closure, and then the closure is passed to the semantics of the tag, which then invokes a 
closure. In the present invention, a tag handler, which is the run-time representation of a 
custom action, has three new methods: 
5 doStart ( ) 

doBody ( ) 

doEnd() 

In other words, the "dolt ( )" method of the closure approach is split into three parts, which can 
be implemented in Java (unlike a true closure). The key idea is that an implementation of an 
10 action provides a method for start tag, a method for end tag, and a method for body. The three 
methods interact in a simple way with the page implementation so that the details of the page 
implementation, including details on how to implement the scripting language, reside in the 
page. 

In particular, the doStart ( ) method is first invoked with attribute value data. It returns a 
15 boolean value indicating if the body needs to be evaluated. The body is evaluated as a stream of 
bytes, into an abstraction, known as a BodyEvaluation object. The BodyEvaluation object is 
then passed into the doBody ( ) method. The doBody ( ) method returns true if more body 
evaluations are needed. When no more body evaluations are needed, the doEnd ( ) method is 
evaluated last. 

20 Thus, rather than creating the complex "closure" abstraction that corresponds to the 

body, the present invention "in-lines" the evaluation of the body. As shown in Figure 5, the 
doStart ( ) method processes the start tag and determines if the body needs to be evaluated. If 
so, a body evaluation buffer is passed to the doBody ( ) method for body evaluation. The 
doBody ( ) method may be evaluated many times using a different buffer. Once the body 

25 evaluation is complete, the doEnd ( ) method completes the processing. 



If a closure were used, one would have to pass the capability of evaluating the body, 
i.e. create an abstraction that is capable of evaluating body as many times as needed. The 
code must generally be taken out of order (context). This abstraction is generally very 
difficult to create, and not really possible using Java. The present invention, however, does 
not require the creation of the closure abstraction. As shown in Figure 6, the code of Figure 4 
can be translated using the present invention into Java code, without using a closure. 

For the present application, the full power and flexibility of a closure is not required. 
Note that unlike a closure, the mechanism of the present invention does not require any 
external context information. The scripting details of the present invention match any nesting 
of the action, so that the structure corresponding to the original scripting is preserved and the 
present invention works regardless of the scripting language used. In the present invention, 
only a body evaluation buffer is needed, and buffers are universally supported. 

In one embodiment, the JSP page implementation instantiates (or reuses) a tag handler 
object for each action in the JSP page. This handler object is a Java object that implements 
the javax.servlet.jsp.tagext.Tag interface. In many cases, the action element has an empty 
body (no text between the start and the end tag). In this common case, the tag handler's 
method doStart ( ) is invoked, passing in the values for the attributes to the action and a 
pageContext object. The pageContext object encapsulates implementation dependent features 
and provides convenience methods, such as getter methods to obtain references to various 
request-time objects. The doStart ( ) method then performs the desired action. The 
pageContext object provides access to all the implicit objects (including the request object, 
for instance) to the handler. 

When a custom tag introduces some new identifiers, a 
javax.servletjsp.tagext.TagExtralnfo object is involved at JSP translation time (not at 
request-time). This object indicates the names and types of the scripting variables that will be 
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assigned objects (at request time) by the action. The only responsibility of the tag author is to 
indicate this information in the TagExtramfo object. The corresponding Tag object must add 
the objects to the pageContext object. It is the responsibility of the JSP translator to 
automatically supply all the required code to do the "synchronization" between the 
5 pageObject values and the scripting variables. 

In general, the body of an action may contain other custom and core tags and scripting 
elements, as well as uninterpreted template text. If an action element has a non-empty body, 
two additional methods need to be implemented by the tag handler object. Recall that the 
doStart ( ) method is always invoked first. This method actually returns a boolean value that 
10 indicates whether the body of the action should be evaluated or not. If so, the body is 

evaluated into a nested stream that is abstracted as a BodyEvaluation object, then the doBody 
( ) method of the tag handler object is invoked with the BodyEvaluation object. 

The doBody ( ) method also returns a boolean value. In this case, the value indicates 
whether the JSP page should do further reevaluations of the body text. Note that since 
15 server-side objects (accessible via pageContext, or through nested handlers) may have 

changed, each evaluation may produce very different content for the BodyEvaluation object. 
When no additional body evaluations are needed, a final doEnd ( ) method is invoked. Like 
the doStart ( ) method, the doEnd ( ) method provides synchronization actions between the 
pageContext data and the scripting variables in the JSP page. 
20 The following examples are provided to further explain the operation of the present 

invention. 

Call Functionality, no Body 

<foo attl= att2= " ..." att3= /> 

In this case, a FooTag tag handler would be defined that implements the Tag interface with 
25 null methods for doBodyO and doEnd ( ). The doStart ( ) method would take the attribute 
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value information, interact with the pageContext data, and invoke into the appropriate 
functionality. In this example, no TagExtralnfo information is needed as the action defines 
no objects accessible to the scripting variables. 

5 Call Functionality, No Body, Define Object 
<foo id="myfoo" attl= att2= /> 

After this, an object with name "myfoo" is available to the scripting language. The type of the 
object is provided by the TagExtralnfo for "foo." This example is similar to the previous one, 
except that the doStart ( ) method inserts the appropriate object for the "myfoo" entry. 

10 

Iteration 

<ul> 

<foreach iterate= "row" in="balances"> 
<li>The balance for 

15 account <%= row.getAccount 0 %> is <%= row.getBalance 0 %> 

</foreach> 
</ul> 

The foreach element does not define a new object for later use but it defines (and redefines) a 
20 "row" object that is accessible within its start and end tags. The implementation of this tag 
requires the repeated evaluation of the body of the tag. 

Tag.doStartTagO This method extracts the value of the "in" and iterates the attribute 
values. The value of in ("balances" in this example) is used to get at 
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the result data. The value of iterate ("row" in this example) is used as 
the key on which to store the iteration value. 

The current value of the "out" variable is stored away so it can be used 
in doBody(). 

This method returns true so as to force the evaluation of the body. 

The translation-time information (TagExtralnfo) indicates that this start 

tag introduces a scripting variable of name "row". 
Tag.doBodyO The BodyEvaluation that is passed in represents the evaluation of the 

body of the element where the evaluation has been done in a context 

where the variable "row" is assigned the different rows of the query. 

This method takes that EvaluationBody and inserts it into the "out" 

stream that we had saved aside previously. 
Tag.doEndTagO The only thing that needs to be done is some bookkeeping. 
TagExtralnfo Provides translation-time information. In this case, a new scripting 

variable is declared within the tag but no variables are available after 

the end tag. 



In further detail, a typical action is of the form: 
<bar id="myBar" foo="one"> 
body 

</bar> 

The semantics is carried through a Java object. This object implements the Tag interface, 
which has three methods: 



doStartTag ( ) The instance is passed attribute values. The Tag instance can use this 
data to perform any action it may want. 

At the end of this action some scripting variables maybe assigned from the pageContext 
object, as indicated in the TagExtralnfo data. This method returns an indication of whether 
5 the body of the action should be evaluated; if so, doBody ( ) will be invoked, otherwise 
doEndTag( ) will be invoked. 

doBody ( ) This method is passed a Stream abstraction (i.e. Body evaluation buffer) 

that corresponds to the tag body. The Tag instance can use this abstraction to insert the data 
10 into another Stream, or it can convert it into a String. This method returns an indication of 
whether the body should be reevaluated. Depending on TagExtralnfo values, the JSP 
container will resynchronize some variable values (so a reevaluation of the body will return a 
different value). 

15 doEndTag ( ) This method is invoked after no more doBodyO method evaluation arc 
requested. This gives the Tag handler a last chance to perform cleanup and also the 
opportunity to update the pageContext object. After this method, the JSP container will 
update scripting variables as indicated by the TagExtralnfo data. 

20 hi an alternate embodiment, the doStart ( ) method may return an integer instead of a 

boolean. For example a "0" may be used to skip the body evaluation, a "1" may be used to 
require a body evaluation, etc. The doBody ( ) method may also be broken into two separate 
methods: doInitBody ( ) and doAfterBody ( ). The doInitBody ( ) pre-processes the 
BodyEvaluation buffer before the first evaluation (i.e. only happens once). Then the 

25 doAfterBody ( ) method functions much like the standard doBody ( ) method discussed 
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above. The doEnd ( ) method can likewise return a value to either skip the processing of the 
reset of the page (i.e. if an error occurred) or to continue processing the page. Also, instead of 
passing in attribute values, a Java Bean mechanism maybe used to set the variable values. 

Those skilled in the art will appreciate that various adaptations and modifications of the 
5 just-described preferred embodiment can be configured without departing from the scope and 
spirit of the invention. Therefore, it is to be understood that, within the scope of the appended 
claims, the invention may be practiced other than as specifically described herein. 
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CLAIMS 

What is claimed is : 

1 1 . A multi-lingual tag extension mechanism for providing tag library extension 

2 functionality, the mechanism comprising: 

3 a doStart ( ) method; 

4 a doBody ( ) method; and 

5 a doEnd ( ) method. 

1 2. The mechanism of Claim 1 , wherein the body is evaluated as a BodyEvaluation 

2 obj ect, which is passed into the doBody ( ) method. 

1 3. The mechanism of Claim 2, wherein the doBody ( ) method returns "true" if more 

2 body evaluations are needed. 

l 4. The mechanism of Claim 2, wherein the doStart method returns a boolean value, 

l 5. The mechanism of Claim 2, wherein the doStart method returns an integer value. 

1 6. The mechanism of Claim 2, wherein the doStart ( ) method is first invoked with 

2 attribute value data, and returns a boolean value indicating if a body needs to be evaluated. 

1 7. The mechanism of Claim 3 , wherein when no more body evaluations are needed, the 

2 doEnd ( ) method is evaluated, and any scripting variables which have been created or updated 

3 are synchronized. 

1 8 . The mechanism of Claim 7, wherein the doBody ( ) evaluations are nested. 

1 9. The mechanism of Claim 1, wherein a tag structure corresponding to an original 

2 scripting page is preserved during a page translation. 

1 10. The mechanism of Claim 9, wherein the mechanism is implemented in a 

2 JavaServer Pages environment. 

1 11. The mechanism of Claim 1 0, wherein the doEnd ( ) method returns a value 

2 indicating whether to continue processing the page. 
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1 12. The mechanism of Claim 2, wherein the BodyEvaluation object does not contain 

2 an entire closure context. 

1 1 3 . A method for processing an action in a Web page to provide tag library extension 

2 support, the method comprising: 

3 creating a doStart ( ) method; 

4 creating a doBody ( ) method; and 

5 creating a doEnd ( ) method. 

1 1 4. The method of Claim 1 3 , wherein a BodyEvaluation obj ect is passed to the 

2 doBody ( ) method for processing. 

1 15. The method of Claim 1 4, wherein the doStart ( ) method is first invoked with 

2 attribute value data, and returns a boolean value indicating if a body needs to be evaluated. 

1 16. The method of Claim 14, wherein attribute values are set using a Java Bean 

2 mechanism. 

1 17. The method of Claim 14, wherein the doBody ( ) method returns "true" if more 

2 body evaluations are needed. 

1 18. The method of Claim 17, wherein when no more body evaluations are needed, the 

2 doEnd ( ) method is evaluated, and any scripting variables which have been created or updated 

3 are synchronized. 

1 19. The method of Claim 1 8, wherein the doBody ( ) evaluations are nested. 

1 20. The method of Claim 14, wherein the method is implemented in a JavaServer Pages 

2 environment. 

1 21 . The method of Claim 14, wherein the doBody ( ) method comprises a dolnitBody ( ) 

2 method and a doAfterBody ( ) method, and wherein the dolnitBody ( ) method is executed only 

3 during a first iteration of the body evaluation. 
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1 22. A method for translating an action tag in a JavaServer Page, wherein the method 

2 provides support for multiple scripting languages, the method comprising: 

3 (a) generating and storing code for any attribute values in a tag instance; 

4 (b) instantiating the tag; 

5 (c) invoking a doStart ( ) method; 

6 (d) creating a BodyEvaluation object if necessary; 

7 (e) If a (evaluate_body) result is true, then 

8 (i) mvoking a doBody ( ) method on the BodyEvaluation object; 

9 (ii) if the doBodyO method returns true, then goto (e) 

10 (f) invoking a doEnd ( ) method on the tag of the tag instance; and 

1 1 (g) synchronizing any indicated scripting variables. 

1 23 . A computer readable medium including computer program code for providing a 

2 multi- lingual tag extension mechanism, the computer readable medium comprising: 

3 computer program code for invoking a doStart ( ) method; 

4 computer program code for invoking a doBody ( ) method; and 

5 computer program code for invoking a doEnd ( ) method. 

1 24. A computer system providing a multi-lingual tag extension mechanism, the 

2 computer system comprising: 

3 a procesor; and 

4 a computer program operating on the processor to translate an action tag, the computer 

5 program including computer program code for invoking a doStart ( ) method, a doBody ( ) 

6 method, and a doEnd ( ) method for each action tag in a Web page. 

1 25 . A method of providing a tag library interface mechanism, the method comprising: 

2 providing a doStart ( ) method; 

3 providing a doBody ( ) method; and 
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4 providing a doEnd ( ) method; 

5 wherein a tag can be translated in an "in-line" manner without knowledge of the 

6 scripting language and without using a closure. 
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ABSTRACT 

A multi-lingual tag extension mechanism suitable for use with the JavaServer Pages' 0 
platform. Rather than creating a closure abstraction, the present invention "in-lines" a body 
evaluation for the tags. A doStart ( ) method processes a start tag and determines if a body 
needs to be evaluated. If so, a body evaluation buffer is passed to a doBody ( ) method for 
body evaluation. Once the body evaluation is complete, a doBnd ( ) method completes the 
processing by synchronizing the variables. The scripting details of the present invention 
match any nesting of the tag, so the at the structure corresponding to the original scripting is 
preserved. Furthermore, the present invention is not dependent on the specifics of the 
scripting language used to form the Web page. 
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(Mte_v\V 



HTTP 



<html> 

<isp:useBean id="clock" 

class-'calendar.isoCalendar" J> 
<ul> ~ 

<H>Day: <%=clock.getDavQfMonthn %> 
<Ii>Yean <%=clock.getYearn %> 
</vA> 
</html> 



JSP tag library 



JavaServer Pages 
Specification 



^ Specification-compliant tool 




JSP pages 

+ 

HTML pages 

+ 

server side code 

+ 

tag library 



JSP-compliant 
container and 
Web Browser 



JSP tag library 



fi$Mt 3 



JSP Page 



stuffl 



<foo> 

stuf£2 

</foo> 



stufB 





translation 


Java Code 


j 



class TheJSPPage { 

run ( request, response) { 
out.println("stuffl") 

Tc = new Closure f stuffD 
f = new Foo Tm pl (k> 
f.dolt fout> 

out.prbatln("stufD") 

} 

\l 



Tag Library 



class FooJmpl { 

Foolmpl (Closure k) { 
this.k = k 

} 

doIt(Stream out) { 

k.invokeClosure(out); 
// all this is pseudo-code 
// there is no Java mechanism 
//for this 

} 

} 



b = f.doStart ( ) 

if(b) 

repeat: Evaluate the Body 
b = f.doBody() 

if (b) goto repeat 
f.doEnd() 



JSP Page 



stuffl 
<foo> 

stuff2 

</foo> 
stufB 



translation 



t 

Java Code 
class TheJSPPage { 

run ( request, response) { 
out.println("stuffl "); 
boolean b; 

f = new FooJmplO; 
b = f.doStartO; 
if(b){ 

repeat: 

stuff2; 

b=f.doBodyO; 
if (!b) goto repeat; 
f.doEnd(); 

} 

out.printhi("stufB ") 



Tag Library 

class FooLnpl { 

// data like "out" is available via 
// methods not shown here 
doStartO { 

// stuff to do on start 

} 

doBodyO { 

// stuff to do after a body 
// evaluation 

} 

doEndO { 

//stuff to do on end 

} 



